home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1993 / Internet Info CD-ROM (Walnut Creek) (1993).iso / inet / internet-drafts / draft-ietf-pppext-cipx-02.txt < prev    next >
Text File  |  1993-04-13  |  46KB  |  1,433 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Internet Area - PPPEXT Working Group                       Saroop Mathur
  8. Internet Draft                                             Mark S. Lewis
  9.                                                            Telebit Corp.
  10. Expires in six months                                         April 1993
  11.  
  12.  
  13.              Compressing IPX Headers Over WAN Media (CIPX)
  14.  
  15.  
  16. Status of this Memo
  17.  
  18.      This draft is a proposed standard protocol for the Internet
  19.      community and requests discussion and suggestions for improvement.
  20.      This document is being submitted to the Internet Engineering Task
  21.      Force (IETF) through the Point-to-Point Protocol Extensions
  22.      (PPPEXT) Working Group.  Comments should be sent to the authors and
  23.      the ietf-ppp@ucdavis.edu mailing list.
  24.  
  25.      Distribution of this memo is unlimited.
  26.  
  27.      This document is an Internet Draft.  Internet Drafts are working
  28.      documents of the IETF, its Areas, and its Working Groups.  Internet
  29.      Drafts are valid for a maximum of six months.  Internet Drafts may
  30.      be updated, replaced, or obsoleted by other documents at any time.
  31.  
  32. Abstract
  33.  
  34.      This document describes a method for compressing the headers of IPX
  35.      datagrams (CIPX).  With this method, it is possible to
  36.      significantly improve performance over lower speed wide area
  37.      network (WAN) media.  For normal IPX packet traffic, CIPX can
  38.      provide a compression ratio of approximately 2:1 including both IPX
  39.      header and data.  This method can be used on various type of WAN
  40.      media, including those supporting PPP and X.25.
  41.  
  42.  
  43.  
  44.  
  45.  
  46.  
  47.  
  48.  
  49.  
  50.  
  51.  
  52.  
  53.  
  54.  
  55.  
  56.  
  57.  
  58. Mathur, Lewis            expires in six months                  [Page 1]
  59. DRAFT                             CIPX                        April 1993
  60.  
  61.  
  62. Introduction
  63.  
  64.      Internetwork Packet Exchange (IPX) is a protocol defined by the
  65.      Novell Corporation.  It is derived from the Internet Datagram
  66.      Protocol (IDP) protocol of the Xerox Network Systems (XNS) family
  67.      of protocols.  IPX is a datagram, connectionless protocol that does
  68.      not require an acknowledgment for each packet sent.  The IPX
  69.      protocol corresponds to the network layer of the ISO model.
  70.  
  71.      Usually, there is a transport layer protocol above IPX.  The most
  72.      common transport protocol is the Netware Core Protocol (NCP), which
  73.      is used for file server access.  The Sequenced Packet Exchange
  74.      (SPX) is the reliable connection-based transport protocol commonly
  75.      used by applications.
  76.  
  77.      The IPX packet consists of a 30 octet IPX header, usually followed
  78.      by the transport layer protocol header.  The NCP header is 6 octets
  79.      in length.  The SPX header is 12 octets in length.
  80.  
  81.      Two strategies are described below for compressing IPX headers.
  82.      This specification requires that implementations of CIPX support
  83.      both IPX header compression strategies.  These header compression
  84.      algorithms are based on those Van Jacobson described [1] for TCP/IP
  85.      packets.
  86.  
  87.      The first strategy is to compress only the IPX header.  This
  88.      compression algorithm can be used to compress any IPX packet,
  89.      without affecting the transport protocol.  This algorithm
  90.      compresses a 30 octet IPX header into a one to seven octet header.
  91.  
  92.      The second strategy is to compress the combined IPX and NCP
  93.      headers.  This algorithm compresses only NCP packets with NCP type
  94.      of 0x2222 and 0x3333.  This algorithm compresses a 36 octet NCP/IPX
  95.      header into a one to eight octet header.
  96.  
  97.      Lastly, note that it is possible, and many times desirable, to use
  98.      this type of header compression in conjunction with some type of
  99.      data compression.  After intelligently compressing the packet
  100.      header, data compression can be effective in reducing packet size
  101.      further.  It is important that data compression should be done
  102.      after header compression.  Conversely, data decompression should be
  103.      done before header decompression.
  104.  
  105.  
  106.  
  107.  
  108.  
  109.  
  110.  
  111.  
  112.  
  113. Mathur, Lewis            expires in six months                  [Page 2]
  114. DRAFT                             CIPX                        April 1993
  115.  
  116.  
  117. IPX Compression Algorithm
  118.  
  119.      The normal IPX header consists of the following fields: checksum,
  120.      packet length, transport control (hop count), packet type,
  121.      destination and source address fields.
  122.  
  123.  
  124.                           +-----------------------+
  125.                           |       Checksum        |
  126.                           +-----------------------+
  127.                           |     Packet Length     |
  128.                           +-----------+-----------+
  129.                           |    Hops   |Packet Type|
  130.                           +-----------+-----------+
  131.                           |      Destination      |
  132.                           |        Address        |
  133.                           |      (12 Octets)      |
  134.                           +-----------------------+
  135.                           |        Source         |
  136.                           |        Address        |
  137.                           |      (12 Octets)      |
  138.                           +-----------------------+
  139.  
  140.                               IPX PACKET HEADER
  141.  
  142.  
  143.      The IPX header diagram above is shown without the unnecessary field
  144.      alignment details.  Consider each field of the IPX header
  145.      separately, and how it typically changes.
  146.  
  147.      Historically, Novell has not used the Checksum field in the IPX
  148.      header, and has required that this field be set to 0xFFFF.  Since
  149.      the Checksum field remains constant, it is clear that the value can
  150.      be compressed.
  151.  
  152.      Where Checksums are implemented (not 0xFFFF), the Checksum MUST be
  153.      included in the compressed packet.  Recalculating the checksum
  154.      would destroy the end-to-end reliability of the connection. Note
  155.      that Checksums are now implemented in the Fault Tolerant Servers.
  156.  
  157.      For most links, the Packet Length can be determined from the MAC
  158.      layer.  There are cases in which the length cannot be determined
  159.      from the MAC layer.  For example, some hardware devices pad packets
  160.      to a required minimum length.  For links where it is not possible
  161.      to determine the IPX packet length from the MAC layer, packet
  162.      length needs to be included in the compressed packet.
  163.  
  164.      The Transport Control (Hops) field usually does not change between
  165.  
  166.  
  167.  
  168. Mathur, Lewis            expires in six months                  [Page 3]
  169. DRAFT                             CIPX                        April 1993
  170.  
  171.  
  172.      two end-points.  For the purposes of compression, we will assume
  173.      that it never changes, and will not examine this field when
  174.      determining a connection.
  175.  
  176.      The Packet Type field is constant for any connection.
  177.  
  178.      The Destination and Source Address fields are each made up of 12
  179.      octets: Network (4 octets), Node (6 octets), and Socket (2 octets)
  180.      fields.  For any specific IPX connection, the Destination and
  181.      Source Address fields are constant.
  182.  
  183.      Hence, the fields that may need to be included in the compressed
  184.      IPX header are the Checksum and the Packet Length.
  185.  
  186.      While using this IPX header compression algorithm, packets can be
  187.      lost.  The loss of an Initial packet presents a problem.  In this
  188.      case, if the sender later tries to send a compressed packet, the
  189.      receiving end cannot decompress the packet correctly.
  190.  
  191.      Sufficient information is not available in the IPX header to
  192.      determine when a re-transmission has occured.  For this reason, it
  193.      is necessary that the sender of an Initial packet be guaranteed
  194.      that the packet has been received.  Therefore, we provide a
  195.      mechanism for Confirmation of an Initial packet.
  196.  
  197.  
  198.  
  199.  
  200.  
  201.  
  202.  
  203.  
  204.  
  205.  
  206.  
  207.  
  208.  
  209.  
  210.  
  211.  
  212.  
  213.  
  214.  
  215.  
  216.  
  217.  
  218.  
  219.  
  220.  
  221.  
  222.  
  223. Mathur, Lewis            expires in six months                  [Page 4]
  224. DRAFT                             CIPX                        April 1993
  225.  
  226.  
  227. NCP/IPX Header Compression
  228.  
  229.      Since most IPX packets are Netware Core Protocol packets (packet
  230.      type 17), compressing the NCP header will give us added
  231.      performance.  A minimal CIPX implementation MUST also implement
  232.      NCP/IPX compression.
  233.  
  234.  
  235.                                +------------+
  236.                                |    NCP     |
  237.                                |    Type    |
  238.                                +------------+
  239.                                |  Sequence  |
  240.                                |   Number   |
  241.                                +------------+
  242.                                | Connection |
  243.                                |(low octet) |
  244.                                +------------+
  245.                                |   Task     |
  246.                                |   Number   |
  247.                                +------------+
  248.                                | Connection |
  249.                                |(high octet)|
  250.                                +------------+
  251.  
  252.                                  NCP HEADER
  253.  
  254.  
  255.      The NCP header is 6 octets in length consisting of the following
  256.      fields: NCP type, sequence number, connection number and task
  257.      number.
  258.  
  259.      The NCP type field values that are currently defined are:
  260.  
  261.  
  262.           1111   Create Connection
  263.           2222   NCP request from workstation
  264.           3333   NCP reply from file server
  265.           5555   Destroy Connection
  266.           7777   Burst Mode Packet
  267.           9999   Server Busy Packet
  268.  
  269.  
  270.      This NCP header compression algorithm only compresses packets that
  271.      have a type field value of 0x2222 or 0x3333.  All other types of
  272.      packets are not compressed at the NCP level.
  273.  
  274.      If NCP type is 0x2222, then this packet is a request from the
  275.  
  276.  
  277.  
  278. Mathur, Lewis            expires in six months                  [Page 5]
  279. DRAFT                             CIPX                        April 1993
  280.  
  281.  
  282.      client to the server.  Conversely if NCP type is 0x3333, this is a
  283.      response from the server to the client.
  284.  
  285.      The connection number is a constant for a given connection.
  286.  
  287.      The sequence number is increased by one for each new request.
  288.      Hence the sequence number can be determined implicitly.  The
  289.      decompressor increments the sequence number for each compressed
  290.      packet it receives for a connection.
  291.  
  292.      The task number can change unpredictably, although it might remain
  293.      constant for several packets.  If the NCP task number is different
  294.      from the last one for this connection, the NCP task number must be
  295.      included.
  296.  
  297.      If the NCP packet is lost, it will be retransmitted through the
  298.      normal transport layer mechanisms.  The Initial NCP packet does not
  299.      require confirmation, as a re-transmitted packet can be easily
  300.      identified.  This is accomplished by comparing the sequence number
  301.      of the packet to the sequence number of the previous packet.  If
  302.      the sequence number is not exactly one greater than the previous
  303.      packet, a new Initial packet must be sent, although the same
  304.      connection slot may be used.
  305.  
  306.      In the event of compressed packet loss, the sequence number will be
  307.      too small.  When the IPX Checksum is present, the loss can be
  308.      determined at the destination system by an incorrect checksum.
  309.      When there is no checksum present, the loss is more likely to be
  310.      detected upon receiving a later retransmission.
  311.  
  312. NCP Burst Mode Packets
  313.  
  314.      The burst mode protocol uses the NCP type value of 0x7777.  This
  315.      type of packet does not have the normal NCP header described above.
  316.      Instead, it has a 36 octet burst header.  The above NCP header
  317.      compression algorithm should not be used to compress this packet.
  318.      The IPX header in this packet is still compressible with the IPX
  319.      header compression algorithm described.
  320.  
  321. SPX Packets
  322.  
  323.      SPX packets are typically used by applications which require
  324.      reliable service such as print servers.  It is possible to apply a
  325.      similar NCP/IPX technique to SPX/IPX packets.  At this time, we
  326.      have not described such a mechanism.  The IPX header in this packet
  327.      is still compressible with the IPX header compression algorithm
  328.      described.
  329.  
  330.  
  331.  
  332.  
  333. Mathur, Lewis            expires in six months                  [Page 6]
  334. DRAFT                             CIPX                        April 1993
  335.  
  336.  
  337. Compression Header
  338.  
  339.      IPX compression should be negotiated by some means (eg. IPXCP or
  340.      IPXWAN).  Each end must negotiate the desired options, such as the
  341.      maximum number of concurrent connections which will be maintained
  342.      in each direction.  Once IPX compression is negotiated, all IPX
  343.      packets sent over that link have a CIPX header added to the
  344.      beginning of the packet.
  345.  
  346.      The one octet CIPX header is added even when a regular IPX packet
  347.      is sent over the link.  By including the CIPX header on every
  348.      packet, we support the ability to run CIPX over various WAN links
  349.      as if it were a normal IPX packet.  It does not rely on any new
  350.      link specific packet demultiplexing.
  351.  
  352.      Implementations of this compression protocol must maintain send and
  353.      receive tables indicating the state of each connection.  The
  354.      original header for each connection is stored in a "slot".
  355.      Typically, each client-server connection will use a separate slot.
  356.      Both sides keep a copy of the full IPX header corresponding to each
  357.      slot.  The sending side (compressor) uses this information to
  358.      determine the fields that have changed.  The receiving side
  359.      (decompressor) uses this information to reconstruct the original
  360.      packet header.
  361.  
  362.      The CIPX packet header specifies the type of the packet and any
  363.      options for that packet.  The basic header is one octet in length.
  364.  
  365.  
  366.        7   6   5   4   3   2   1   0
  367.      +---+---+---+---+---+---+---+---+
  368.      |   |   |   |   |   |   |   |   |
  369.      +---+---+---+---+---+---+---+---+
  370.        ^   ^   ^   ^   ^   ^   ^   ^
  371.        |   |   |   |   |   |   |   |
  372.        |   |   |   |   |___|___|___|___ Packet Type
  373.        |   |   |   |                    0    Compressed
  374.        |   |   |   |                    1    Regular
  375.        |   |   |   |                    3    Confirmed Initial
  376.        |   |   |   |                    5    Confirm
  377.        |   |   |   |                    7    Unconfirmed Initial
  378.        |   |   |   |                    9    Reject
  379.        |   |   |   |                   11-15 Reserved
  380.        |   |   |   |
  381.        |__ |__ |__ |___________________ Packet Type Dependent Flags
  382.  
  383.                           FLAGS OCTET
  384.  
  385.  
  386.  
  387.  
  388. Mathur, Lewis            expires in six months                  [Page 7]
  389. DRAFT                             CIPX                        April 1993
  390.  
  391.  
  392.      As can be seen above, the low order bits specify the packet type.
  393.      All Compressed packets have a lowest bit of zero.  The other packet
  394.      types are odd numbers.
  395.  
  396.      Note that the Flags octet MUST NOT contain the value 0xFF.  This is
  397.      necessary to distinguish the CIPX flags octet from a normal IPX
  398.      header with a 0xFFFF checksum field.  It is important to be able to
  399.      recognize a normal IPX header regardless of the state of
  400.      compression.  It is possible with some link layer protocols such as
  401.      X.25 Permanent Virtual Circuits that one end of the link may fail
  402.      and start sending IPX packets.
  403.  
  404.      Each packet type has associated flag bits, which are called Packet
  405.      Type Dependent Flags.  Different packet types have different Packet
  406.      Type Dependent Flags.  All bits that are reserved or are not
  407.      specified must be set to zero.
  408.  
  409.      Since none of the packet types other than Compressed currently uses
  410.      any of the flag bits, the packet type field could easily be
  411.      expanded.  Any future expansion must ensure that at least one of
  412.      the bits remains zero.
  413.  
  414.  
  415.  
  416.  
  417.  
  418.  
  419.  
  420.  
  421.  
  422.  
  423.  
  424.  
  425.  
  426.  
  427.  
  428.  
  429.  
  430.  
  431.  
  432.  
  433.  
  434.  
  435.  
  436.  
  437.  
  438.  
  439.  
  440.  
  441.  
  442.  
  443. Mathur, Lewis            expires in six months                  [Page 8]
  444. DRAFT                             CIPX                        April 1993
  445.  
  446.  
  447. Compressed Packet
  448.  
  449.      This type of packet does not contain a packet header (either 30
  450.      byte IPX, or 36 byte NCP).  A slot number indicates to the receiver
  451.      which saved header to use to formulate the original packet header
  452.      before passing the packet up to IPX.
  453.  
  454.  
  455.        7   6   5   4   3   2   1   0
  456.      +---+---+---+---+---+---+---+---+
  457.      |   |   |   |   | 0 | 0 | 0 | 0 |
  458.      +---+---+---+---+---+---+---+---+
  459.        ^   ^   ^   ^   ^   ^   ^   ^
  460.        |   |   |   |   |   |   |   |
  461.        |   |   |   |   |   |   |   |___ Packet Type
  462.        |   |   |   |   |   |   |        0    Compressed Packet
  463.        |   |   |   |   |   |   |
  464.        |   |   |   |   |___|___|_______ Reserved (Must be zero)
  465.        |   |   |   |
  466.        |   |   |   |___________________ Task Number (NCP only)
  467.        |   |   |                        0    Assume same as last packet
  468.        |   |   |                        1    Included in packet
  469.        |   |   |
  470.        |   |   |_______________________ Length
  471.        |   |                            0    Determine from MAC length
  472.        |   |                            1    Included in packet
  473.        |   |
  474.        |   |___________________________ Checksum
  475.        |                                0    Assume 0xFFFF
  476.        |                                1    Included in packet
  477.        |
  478.        |_______________________________ Slot Number
  479.                                         0    Assume same as last packet
  480.                                         1    Included in packet
  481.  
  482.  
  483.      Consider each flag in the flags octet, looking at the high order
  484.      bits working toward the lower order bits.  Each of the fields is
  485.      optional, but if present will be found in the same order in the
  486.      compressed packet header.
  487.  
  488.      Slot Number
  489.  
  490.           The slot number flag indicates the slot number field is
  491.           included in the compressed packet.  The slot number field is
  492.           one octet in length and specifies the number of the slot which
  493.           corresponds to the Initial packet header.  Slots are numbered
  494.           starting at zero and continue to the maximum number of slots
  495.  
  496.  
  497.  
  498. Mathur, Lewis            expires in six months                  [Page 9]
  499. DRAFT                             CIPX                        April 1993
  500.  
  501.  
  502.           minus one.
  503.  
  504.           By default, slot compression is disabled, and every packet has
  505.           the slot number included.  If negotiated, slot compression can
  506.           be enabled for those slots which were created by the
  507.           Unconfirmed Initial packet.  When slot compression is enabled
  508.           and the packet will be compressed using the same slot as for
  509.           the last packet, the compressor clears the slot number flag
  510.           and omits the slot number field.
  511.  
  512.                Implementation Note:
  513.  
  514.                Slot compression MUST only be enabled in a receiver which
  515.                can account for all erroneous and discarded packets.
  516.                When a packet has been discarded, the slot number is
  517.                indeterminate for future packets.  The decompressor MUST
  518.                discard all further packets until a slot number is
  519.                received.
  520.  
  521.      Checksum
  522.  
  523.           If the checksum flag is set, the compressed packet will
  524.           include the 2 octet checksum.  If this flag is not set, then
  525.           the decompressor assumes the checksum is 0xFFFF.  Note that
  526.           meaningful checksums must be included in the packet with the
  527.           flag set.
  528.  
  529.      Length
  530.  
  531.           The length flag indicates the inclusion of the IPX data length
  532.           field in the compressed packet.  This is the Length field from
  533.           the original IPX packet header.  It specifies the length of
  534.           IPX header and data in the packet prior to compression.  It
  535.           does not include the CIPX compression field such as flags,
  536.           slot number, checksum, length field, or the NCP task number.
  537.           Note that it is preferable to determine the length field from
  538.           the MAC layer whenever possible, by subtracting the length of
  539.           the compression header fields and adding the length of the
  540.           saved packet header.
  541.  
  542.           Since every octet is significant over lower speed WAN links,
  543.           an optimization is used in the specification of the length.
  544.           It can be specified as a one, two or three octet field.  If
  545.           the length is in the range 0 to 127, then it is specified as a
  546.           one octet field.  If the length is in the range 128 to 16383,
  547.           it is specified as a two octet field in high to low order,
  548.           with the first octet in the range 128 to 191.  Otherwise, if
  549.           the length is greater than 16383, the first octet contains
  550.  
  551.  
  552.  
  553. Mathur, Lewis            expires in six months                 [Page 10]
  554. DRAFT                             CIPX                        April 1993
  555.  
  556.  
  557.           192, and the second and third octets contain the full length.
  558.           (This scheme is extensible to 8 octets, but currently is not
  559.           required in the IPX protocol suite.)
  560.  
  561.  
  562.           +-+-+-+-+-+-+-+-+
  563.           |0|   length    |   length < 128
  564.           +-+-+-+-+-+-+-+-+
  565.  
  566.           ONE OCTET LENGTH FIELD
  567.  
  568.  
  569.  
  570.           +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  571.           |1 0|          length           |   length < 16384
  572.           +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  573.  
  574.           TWO OCTET LENGTH FIELD
  575.  
  576.  
  577.  
  578.           +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  579.           |1 1 0 0 0 0 0 0|            length             |  length < 65535
  580.           +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  581.  
  582.           THREE OCTET LENGTH FIELD
  583.  
  584.  
  585.      Task Number
  586.  
  587.           The NCP task number flag indicates the NCP task number is
  588.           included in the compressed packet (see NCP/IPX compression
  589.           above).  Otherwise, we use the same NCP task number as that of
  590.           last packet.
  591.  
  592.      Based upon the bits set in the flags octet, optional portions are
  593.      included in the compressed IPX header.  The minimum compressed IPX
  594.      header contains only the Flags octet.  All fields in the original
  595.      IPX header have been compressed out of the header.  The maximum
  596.      compressed IPX header can include up to 7 octets, the Flags, Slot,
  597.      Checksum (2 octets), and Length (3 octets) fields, or 8 octets if
  598.      the NCP Task Number is included.  The minimum and maximum
  599.      compressed IPX packets are shown below.  Header fields are one
  600.      octet in length except where noted.
  601.  
  602.  
  603.  
  604.  
  605.  
  606.  
  607.  
  608. Mathur, Lewis            expires in six months                 [Page 11]
  609. DRAFT                             CIPX                        April 1993
  610.  
  611.  
  612.  
  613.      +--------+---------
  614.      | Flags  | DATA ...
  615.      |  0x00  |
  616.      +--------+---------
  617.  
  618.      MINIMUM COMPRESSED IPX PACKET
  619.  
  620.  
  621.  
  622.      +--------+--------+---------+---------+---------
  623.      | Flags  |  Slot  |Checksum | Length  | DATA ...
  624.      |  0xE0  | Number |2 octets |3 octets |
  625.      +--------+--------+---------+---------+---------
  626.  
  627.      MAXIMUM COMPRESSED IPX PACKET
  628.  
  629.  
  630.  
  631.      +--------+--------+---------+---------+--------+---------
  632.      | Flags  |  Slot  |Checksum | Length  |NCP Task| DATA ...
  633.      |  0xF0  | Number |2 octets |3 octets | Number |
  634.      +--------+--------+---------+---------+--------+---------
  635.  
  636.      MAXIMUM COMPRESSED NCP/IPX PACKET
  637.  
  638.  
  639.  
  640.  
  641.  
  642.  
  643.  
  644.  
  645.  
  646.  
  647.  
  648.  
  649.  
  650.  
  651.  
  652.  
  653.  
  654.  
  655.  
  656.  
  657.  
  658.  
  659.  
  660.  
  661.  
  662.  
  663. Mathur, Lewis            expires in six months                 [Page 12]
  664. DRAFT                             CIPX                        April 1993
  665.  
  666.  
  667. Regular Packet
  668.  
  669.      The Regular packet type designates an IPX packet for which no
  670.      compression is desired.  This type of packet is sent when a packet
  671.      cannot be compressed, or a decision is made not to compress it.
  672.  
  673.  
  674.        7   6   5   4   3   2   1   0
  675.      +---+---+---+---+---+---+---+---+
  676.      | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 1 |
  677.      +---+---+---+---+---+---+---+---+
  678.        ^   ^   ^   ^   ^   ^   ^   ^
  679.        |   |   |   |   |   |   |   |
  680.        |   |   |   |   |___|___|___|___ Packet Type
  681.        |   |   |   |                    1    Regular
  682.        |   |   |   |
  683.        |__ |__ |__ |___________________ Reserved (must be zero)
  684.  
  685.  
  686.      The Regular packet is rarely sent.  Usually, the Regular packet is
  687.      sent when there is not enough memory for the overhead of a new
  688.      compression slot.  Also, this type is included for future
  689.      unforeseen changes to the IPX protocol which defeat the
  690.      effectiveness of compression.
  691.  
  692.           Implementation Note:
  693.  
  694.           The Regular Packet can be used for packets that are sporadic,
  695.           which are not worth setting-up a compression slot.  This may
  696.           be hard to determine for specific protocols.  Various methods
  697.           such as hold-down and least-recently-used timers are currently
  698.           being used.
  699.  
  700.      On receipt, the 1 octet header is simply removed and the packet
  701.      passed up to IPX.
  702.  
  703.      The entire IPX packet follows the single Flags octet.  Note for a
  704.      Regular Packet (not compressed or uncompressed), the slot number
  705.      field is not included.
  706.  
  707.  
  708.  
  709.  
  710.  
  711.  
  712.  
  713.  
  714.  
  715.  
  716.  
  717.  
  718. Mathur, Lewis            expires in six months                 [Page 13]
  719. DRAFT                             CIPX                        April 1993
  720.  
  721.  
  722. Confirmed Initial Packet
  723.  
  724.      The Confirmed Initial packet type is used by the compressor to
  725.      inform the decompressor of the original packet header which will be
  726.      used for subsequent compression, and to request Confirmation.  The
  727.      high order 4 bits are reserved for expansion to support additional
  728.      protocols.
  729.  
  730.  
  731.        7   6   5   4   3   2   1   0
  732.      +---+---+---+---+---+---+---+---+
  733.      | 0 | 0 | 0 | 0 | 0 | 0 | 1 | 1 |
  734.      +---+---+---+---+---+---+---+---+
  735.        ^   ^   ^   ^   ^   ^   ^   ^
  736.        |   |   |   |   |   |   |   |
  737.        |   |   |   |   |___|___|___|___ Packet Type
  738.        |   |   |   |                    3     Confirmed Initial
  739.        |   |   |   |
  740.        |__ |__ |__ |___________________ 0     IPX Protocol
  741.                                         1-15  Reserved
  742.  
  743.  
  744.      This type of packet is sent to inform the receiver to associate the
  745.      IPX packet header with a slot number.  This packet is sent each
  746.      time a different header format is sent for a given slot, or when
  747.      the sender has not received a Confirmation Packet from the
  748.      receiver.
  749.  
  750.      The Flags octet lower 4 bits indicate the Confirmed Initial CIPX
  751.      packet type.  The high order 4 bits are reserved for expansion to
  752.      support additional protocols.  The Flags octet is always followed
  753.      by the Slot Number and an ID field.
  754.  
  755.  
  756.      +---------+---------+---------+------------+----------
  757.      |  Flags  |   Slot  |   ID    |    IPX     |  DATA ...
  758.      |   0x03  |  Number |         |   Header   |
  759.      +---------+---------+---------+------------+----------
  760.  
  761.      CONFIRMED INITIAL PACKET
  762.  
  763.  
  764.      For each slot, the ID will increment with every new header sent.
  765.      Different slots may have the same ID.  The combination of slot and
  766.      ID uniquely identify a header.  In practice, the ID octet can be
  767.      any number which is unique for a "reasonably long period" of time.
  768.      A reasonably long period is a function of transmission speed, round
  769.      trip delays, and network load.  There must be very little chance of
  770.  
  771.  
  772.  
  773. Mathur, Lewis            expires in six months                 [Page 14]
  774. DRAFT                             CIPX                        April 1993
  775.  
  776.  
  777.      duplicate slot and ID combinations within this period.  Otherwise,
  778.      there is ambiguity as to which header is being identified.
  779.  
  780.           Implementation Note:
  781.  
  782.           With the use of the ID octet, an implementation does not have
  783.           to hold a packet forever.  If a Confirmed Initial packet goes
  784.           unconfirmed for too long a period, the same packet may be sent
  785.           using another slot.  This allows an implementation to continue
  786.           through the datastream without having to retransmit the same
  787.           Confirmed Initial packet using the same slot.
  788.  
  789.           For many implementations, it may be better to resend the same
  790.           Confirmed Initial packet until a corresponding Confirm packet
  791.           is received.  Using this method, an implementation may avoid
  792.           some of the complexity of choosing which packet to send using
  793.           a slot for which a confirmation has not been received within
  794.           the given period.  The implementation simply resends the same
  795.           packet with the same ID until confirmed.  The choice between
  796.           these two methods is left as an implementation detail.
  797.  
  798.      Note that a Confirmed Initial header is followed by a complete IPX
  799.      packet.
  800.  
  801.  
  802.  
  803.  
  804.  
  805.  
  806.  
  807.  
  808.  
  809.  
  810.  
  811.  
  812.  
  813.  
  814.  
  815.  
  816.  
  817.  
  818.  
  819.  
  820.  
  821.  
  822.  
  823.  
  824.  
  825.  
  826.  
  827.  
  828. Mathur, Lewis            expires in six months                 [Page 15]
  829. DRAFT                             CIPX                        April 1993
  830.  
  831.  
  832. Confirm Packet
  833.  
  834.      The Confirm packet type is used by the decompressor to tell the
  835.      compressor that it has received the Confirmed Initial packet.
  836.  
  837.      When the compressor receives this, it can start sending Compressed
  838.      frames.
  839.  
  840.        7   6   5   4   3   2   1   0
  841.      +---+---+---+---+---+---+---+---+
  842.      | 0 | 0 | 0 | 0 | 0 | 1 | 0 | 1 |
  843.      +---+---+---+---+---+---+---+---+
  844.        ^   ^   ^   ^   ^   ^   ^   ^
  845.        |   |   |   |   |   |   |   |
  846.        |   |   |   |   |___|___|___|___ Packet Type
  847.        |   |   |   |                    5    Confirm
  848.        |   |   |   |
  849.        |__ |__ |__ |___________________ Reserved (must be zero)
  850.  
  851.  
  852.      A Confirm Packet is exactly 3 octets in length.  It consists of the
  853.      Flags, Slot Number and ID fields.  The Slot Number field contains
  854.      the number of the slot which is being acknowledged.  The ID field
  855.      contains the ID of the Confirm Initial Packet which is being
  856.      acknowledged.
  857.  
  858.  
  859.  
  860.      +---------+---------+----------+
  861.      |  Flags  |   Slot  |    ID    |
  862.      |   0x05  |  Number |          |
  863.      +---------+---------+----------+
  864.  
  865.      CONFIRM PACKET
  866.  
  867.  
  868.  
  869.  
  870.  
  871.  
  872.  
  873.  
  874.  
  875.  
  876.  
  877.  
  878.  
  879.  
  880.  
  881.  
  882.  
  883. Mathur, Lewis            expires in six months                 [Page 16]
  884. DRAFT                             CIPX                        April 1993
  885.  
  886.  
  887. Unconfirmed Initial Packet
  888.  
  889.      The Unconfirmed Initial packet type is used by the compressor to
  890.      inform the decompressor of the original packet header which will be
  891.      used for subsequent compression while not requesting confirmation.
  892.  
  893.      After sending an Unconfirmed Initial packet, the compressor may
  894.      immediately send Compressed packets without confirmation.
  895.  
  896.  
  897.        7   6   5   4   3   2   1   0
  898.      +---+---+---+---+---+---+---+---+
  899.      | 0 | 0 | 0 | 0 | 0 | 1 | 1 | 1 |
  900.      +---+---+---+---+---+---+---+---+
  901.        ^   ^   ^   ^   ^   ^   ^   ^
  902.        |   |   |   |   |   |   |   |
  903.        |   |   |   |   |___|___|___|___ Packet Type
  904.        |   |   |   |                    7     Unconfirmed Initial
  905.        |   |   |   |
  906.        |__ |__ |__ |___________________ 0     NCP Protocol
  907.                                         1-15  Reserved
  908.  
  909.  
  910.      This type of packet is sent to inform the receiver to associate the
  911.      IPX packet header with a slot number.  This packet is sent each
  912.      time a different header format is sent for a given slot.
  913.  
  914.      The Flags octet lower 4 bits indicate the Unconfirmed Initial CIPX
  915.      packet type.  The high order 4 bits are reserved for expansion to
  916.      support additional protocols.  The Flags octet is always followed
  917.      by the Slot Number.
  918.  
  919.  
  920.      +---------+---------+------------+-----------+---------
  921.      |  Flags  |   Slot  |    IPX     |    NCP    | NCP
  922.      |   0x07  |  Number |   Header   |   Header  | DATA ...
  923.      +---------+---------+------------+-----------+---------
  924.  
  925.      UNCONFIRMED INITIAL PACKET
  926.  
  927.  
  928.      Note that an Unconfirmed Initial header is followed by a complete
  929.      IPX packet.
  930.  
  931.  
  932.  
  933.  
  934.  
  935.  
  936.  
  937.  
  938. Mathur, Lewis            expires in six months                 [Page 17]
  939. DRAFT                             CIPX                        April 1993
  940.  
  941.  
  942. Reject Packet
  943.  
  944.      The Reject packet type is used by the decompressor to tell the
  945.      compressor that it has received an Initial packet (Confirmed or
  946.      Unconfirmed) with a Flag value which it does not support.  This is
  947.      provided for future expansion.  Any CIPX packet type which is
  948.      unknown to the decompressor MUST be rejected.
  949.  
  950.      When the compressor receives this, it should record the IPX Packet
  951.      Type as uncompressible.  Future packets of this type should be sent
  952.      with only IPX header compression.
  953.  
  954.        7   6   5   4   3   2   1   0
  955.      +---+---+---+---+---+---+---+---+
  956.      | 0 | 0 | 0 | 0 | 1 | 0 | 0 | 1 |
  957.      +---+---+---+---+---+---+---+---+
  958.        ^   ^   ^   ^   ^   ^   ^   ^
  959.        |   |   |   |   |   |   |   |
  960.        |   |   |   |   |___|___|___|___ Packet Type
  961.        |   |   |   |                    9    Reject
  962.        |   |   |   |
  963.        |__ |__ |__ |___________________ Reserved (must be zero)
  964.  
  965.  
  966.      A Reject Packet is exactly 3 octets in length.  It consist of the
  967.      Flags, Slot Number and Rejected Flags fields.  The Slot Number
  968.      field contains the number of the slot of the packet which is being
  969.      rejected.
  970.  
  971.      The Rejected Flags field contains the flag(s) of the unsupported
  972.      packet type and/or packet dependent option. This octet will contain
  973.      the 4-bit packet type of the packet being rejected.  It may also
  974.      include a specific combination of packet type dependent flag(s)
  975.      that is being rejected.  The intention of this field is to provide
  976.      information to the sender about why the packet is being rejected.
  977.      Intelligent implementations can use this information to adjust
  978.      their use of certain packet types or options.
  979.  
  980.           Implementation Note:
  981.  
  982.           The Flags value of 0xFF is not a valid CIPX packet type.
  983.           Hence, such a packet type should be recognized as a standard
  984.           IPX header and forwarded without CIPX processing to the
  985.           appropriate routines.  Under no circumstances should a Flags
  986.           value of 0xFF be rejected in a Reject Packet.
  987.  
  988.  
  989.  
  990.  
  991.  
  992.  
  993. Mathur, Lewis            expires in six months                 [Page 18]
  994. DRAFT                             CIPX                        April 1993
  995.  
  996.  
  997.  
  998.      +---------+---------+----------+
  999.      |  Flags  |   Slot  | Rejected |
  1000.      |   0x09  |  Number |  Flags   |
  1001.      +---------+---------+----------+
  1002.  
  1003.      REJECT PACKET
  1004.  
  1005.  
  1006.  
  1007.  
  1008.  
  1009.  
  1010.  
  1011.  
  1012.  
  1013.  
  1014.  
  1015.  
  1016.  
  1017.  
  1018.  
  1019.  
  1020.  
  1021.  
  1022.  
  1023.  
  1024.  
  1025.  
  1026.  
  1027.  
  1028.  
  1029.  
  1030.  
  1031.  
  1032.  
  1033.  
  1034.  
  1035.  
  1036.  
  1037.  
  1038.  
  1039.  
  1040.  
  1041.  
  1042.  
  1043.  
  1044.  
  1045.  
  1046.  
  1047.  
  1048. Mathur, Lewis            expires in six months                 [Page 19]
  1049. DRAFT                             CIPX                        April 1993
  1050.  
  1051.  
  1052. Compression Negotiation over PPP Links
  1053.  
  1054.      For PPP links [2], the use of header compression can be negotiated
  1055.      by IPXCP [3].  By default, no compression is enabled.
  1056.  
  1057.      The IPX-Compression-Protocol Configuration Option is used to
  1058.      indicate the ability to receive compressed packets.  Each end of
  1059.      the link must separately request this option if bi-directional
  1060.      compression is desired.
  1061.  
  1062.      The PPP Protocol field is set to the same value as the usual IPX
  1063.      packets, and all IPX packets sent over the link MUST conform to the
  1064.      compressed format.
  1065.  
  1066.      A summary of the IPX-Compression-Protocol Configuration Option
  1067.      format to negotiate Telebit IPX header compression (CIPX) is shown
  1068.      below.  The fields are transmitted from left to right.
  1069.  
  1070.  
  1071.       0                   1                   2                   3
  1072.       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  1073.      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1074.      |     Type      |    Length     |    IPX-Compression-Protocol   |
  1075.      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1076.      |  Max-Slot-Id  |    Options    |
  1077.      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1078.  
  1079.  
  1080.      Type
  1081.  
  1082.           3
  1083.  
  1084.      Length
  1085.  
  1086.           6
  1087.  
  1088.      IPX-Compression-Protocol
  1089.  
  1090.           0002 (hex) for Telebit Compressed IPX headers (CIPX).
  1091.  
  1092.      Max-Slot-Id
  1093.  
  1094.           The Max-Slot-Id field is one octet and indicates the maximum
  1095.           slot identifier.  This is one less than the actual number of
  1096.           slots; the slot identifier has values from zero to Max-Slot-
  1097.           Id.
  1098.  
  1099.  
  1100.  
  1101.  
  1102.  
  1103. Mathur, Lewis            expires in six months                 [Page 20]
  1104. DRAFT                             CIPX                        April 1993
  1105.  
  1106.  
  1107.      Options
  1108.  
  1109.           The Options field is one octet, and is comprised of the
  1110.           "logical or" of the following values:
  1111.  
  1112.                0    No options.
  1113.  
  1114.                1    The slot identifer may be compressed.
  1115.  
  1116.                The slot identifier must not be compressed if there is no
  1117.                ability for the PPP link level to indicate an error in
  1118.                reception to the decompression module.  Synchronization
  1119.                after errors depends on receiving a packet with the slot
  1120.                identifier.
  1121.  
  1122.                2    Redefine Compressed Packet type bits 1-3.
  1123.  
  1124.                It was noted earlier that packet types have been chosen
  1125.                such that only the Compressed Packet type is an even
  1126.                number value with the lowest order bit of zero.  All
  1127.                other packet types are odd values with a lowest order bit
  1128.                of one.  The reason for this assignment was to make it
  1129.                possible to determine the Compressed Packet type by
  1130.                examining only one bit.  This make it possible to use all
  1131.                the other 7 bits to indicate status in the Compressed
  1132.                Packet.  The 7 bits are composed of the upper 4 bits
  1133.                which are permanently defined to indicate packet
  1134.                dependent flags, plus bits 1-3 which are otherwise part
  1135.                of the Packet Type.  The upper 4 bits are defined above.
  1136.                The redefinition of bits 1-3 of the Compressed Packet
  1137.                type is left for future expansion.
  1138.  
  1139.                  7   6   5   4   3   2   1   0
  1140.                +---+---+---+---+---+---+---+---+
  1141.                |   |   |   |   |   |   |   | 0 |
  1142.                +---+---+---+---+---+---+---+---+
  1143.                  ^   ^   ^   ^   ^   ^   ^   ^
  1144.                  |   |   |   |   |   |   |   |___ Packet Type
  1145.                  |   |   |   |   |   |   |        0    Compressed Packet
  1146.                  |   |   |   |   |   |   |
  1147.                  |   |   |   |   |___|___|_______ Redefined bits
  1148.                  |   |   |   |
  1149.                  |___|___|___|___________________ Compressed Packet flags
  1150.  
  1151.  
  1152.                By default, this feature in not enabled and this flag is
  1153.                set to zero.  When this flag is set to one, it indicates
  1154.                the desire to use this feature.
  1155.  
  1156.  
  1157.  
  1158. Mathur, Lewis            expires in six months                 [Page 21]
  1159. DRAFT                             CIPX                        April 1993
  1160.  
  1161.  
  1162. Compression Negotiation over IPXWAN Links
  1163.  
  1164.      "IPXWAN" is the protocol Novell uses to exchange necessary router
  1165.      to router information prior to exchanging standard IPX routing
  1166.      information and traffic over WAN datalinks [4].  To negotiate the
  1167.      Telebit compression option, we add an option to the IPXWAN timer
  1168.      request/response packet.
  1169.  
  1170.      The Timer Request packet contains the following Telebit compression
  1171.      option:
  1172.  
  1173.      WOption Number       80        - Define compression type
  1174.      WAccept Option       01        - 0=No, 1=Yes, 3=N/A
  1175.      WOption Data Len     00 03     - Length of option
  1176.      WOption Data         00        - Telebit's compression (CIPX)
  1177.      WOption Data         XX        - Compression options
  1178.      WOption Data         NN        - Compression slots
  1179.  
  1180.  
  1181.      Where the WOption Data fields are:
  1182.  
  1183.      00   Telebit's compression option described in this
  1184.           document (CIPX).
  1185.  
  1186.      XX   Compression options as defined below:
  1187.  
  1188.              0x01   Compress slot ID when possible
  1189.              0x02   Redefine Compressed Packet type bits 1-3.
  1190.  
  1191.      NN   The requested # of compression slots.
  1192.  
  1193.      Accept Option (for compression type) must be set to YES if the
  1194.      option is supported and NO if the option is not supported.  A Timer
  1195.      Response must respond with only one header compression type set to
  1196.      YES.
  1197.  
  1198.      The Timer Response packet that accepts the option will look like
  1199.      this:
  1200.  
  1201.      WOption Number       80        - Define compression type
  1202.      WAccept Option       01        - 0=No, 1=Yes, 3=N/A
  1203.      WOption Data Len     00 03     - Length of option
  1204.      WOption Data         00        - Telebit's compression (CIPX)
  1205.      WOption Data         XX        - Compression options
  1206.      WOption Data         NN        - Compression slots
  1207.  
  1208.  
  1209.  
  1210.  
  1211.  
  1212.  
  1213. Mathur, Lewis            expires in six months                 [Page 22]
  1214. DRAFT                             CIPX                        April 1993
  1215.  
  1216.  
  1217.      Where the WOption Data fields are:
  1218.  
  1219.      00   Telebit's compression option described in this
  1220.           document (CIPX).
  1221.  
  1222.      XX   Compression options as defined below:
  1223.  
  1224.              0x01   Compress slot ID when possible
  1225.              0x02   Redefine Compressed Packet type bits 1-3.
  1226.  
  1227.      NN   The negotiated # of slots (The lower of each side's
  1228.           requested number of slots)
  1229.  
  1230.      IPX packets (except of course IPXWAN packets) are not sent over the
  1231.      link until the IPXWAN negotiations are completed.  Once IPXWAN
  1232.      negotiations are completed, regular IPX packets can be sent over
  1233.      the link.
  1234.  
  1235.      If both ends of the link agree on the compression options, then the
  1236.      IPX packets are sent using the specified options.  If either end of
  1237.      the link does not accept a compression option, then this
  1238.      compression option will not be used.  Compression will be done
  1239.      using any remaining options.  Options, by definition, are not
  1240.      required.  Implementations MUST support CIPX without any options.
  1241.  
  1242.      It is the responsibility of the router sending the IPXWAN Timer
  1243.      Response to inform the other router of the options that will be
  1244.      used.  The Timer Response MUST contain a subset of the options
  1245.      received in a Timer Request.
  1246.  
  1247.      To be clear, IPXWAN is used to set up a symmetrical compression
  1248.      link.  Compression is configured identically in both directions.
  1249.      Each end will use the same number of slots and same compression
  1250.      options.  It is illegal for link ends to use different number of
  1251.      slots or different options.
  1252.  
  1253.  
  1254.  
  1255.  
  1256.  
  1257.  
  1258.  
  1259.  
  1260.  
  1261.  
  1262.  
  1263.  
  1264.  
  1265.  
  1266.  
  1267.  
  1268. Mathur, Lewis            expires in six months                 [Page 23]
  1269. DRAFT                             CIPX                        April 1993
  1270.  
  1271.  
  1272. IPX Compression Performance
  1273.  
  1274.      The performance of this algorithm will depend on the number of
  1275.      active connections and the number of slots negotiated.  If the
  1276.      number of slots is greater than the number of connections, the hit
  1277.      rate should be very high giving a very high compression ratio.  The
  1278.      performance also depends on the average size of the IPX packets.
  1279.      If the average size of packets is small, then compression will
  1280.      result in a more noticeable performance improvement.
  1281.  
  1282.  
  1283.                          avg_data_len + uncomp_header_len
  1284.      Compression ratio = ----------------------------------
  1285.                          avg_data_len + avg_comp_header_len
  1286.  
  1287.  
  1288.      Where 'avg_data_len' is the average length of data in the IPX
  1289.      packet, and 'uncomp_head_len' is the uncompressed header length
  1290.      which is fixed at 30 octets.  Where 'avg_comp_header_len' is the
  1291.      average length of the compressed IPX header.  The length of the
  1292.      minimum compressed IPX header is 1 octet.  The length of the
  1293.      maximum compressed NCP/IPX header is 8 octets (including the NCP
  1294.      task number), but since nothing yet sends packets with a length
  1295.      greater than 16K, 7 octets is the reality.  Perhaps a reasonable
  1296.      'avg_comp_header_len' is 2, assuming the inclusion of the flag and
  1297.      slot number octets.
  1298.  
  1299.      The maximum length of the data in an IPX packet is 546 octets (576
  1300.      octets - 30 octet IPX header), although newer implementations may
  1301.      send packets of up to 4096 octets.  The minimum length of the data
  1302.      in an IPX packet is 1 octet.  Within the normal distribution of
  1303.      small NCP packets, perhaps a reasonable 'avg_data_len' is 26
  1304.      octets.
  1305.  
  1306.  
  1307.  
  1308.  
  1309.  
  1310.  
  1311.  
  1312.  
  1313.  
  1314.  
  1315.  
  1316.  
  1317.  
  1318.  
  1319.  
  1320.  
  1321.  
  1322.  
  1323. Mathur, Lewis            expires in six months                 [Page 24]
  1324. DRAFT                             CIPX                        April 1993
  1325.  
  1326.  
  1327.  
  1328.                               546 + 30
  1329.      Minimal Compression    = -------- =  1.04
  1330.                               546 + 6
  1331.  
  1332.  
  1333.  
  1334.                               1 + 30
  1335.      Maximal Compression    = ------   = 15.50
  1336.                               1 + 1
  1337.  
  1338.  
  1339.  
  1340.                               26 + 30
  1341.      Likely Compression     = -------  =  2.00
  1342.                               26 + 2
  1343.  
  1344. Security Considerations
  1345.  
  1346.      Security issues are not discussed in this memo.
  1347.  
  1348.  
  1349.  
  1350.  
  1351.  
  1352.  
  1353.  
  1354.  
  1355.  
  1356.  
  1357.  
  1358.  
  1359.  
  1360.  
  1361.  
  1362.  
  1363.  
  1364.  
  1365.  
  1366.  
  1367.  
  1368.  
  1369.  
  1370.  
  1371.  
  1372.  
  1373.  
  1374.  
  1375.  
  1376.  
  1377.  
  1378. Mathur, Lewis            expires in six months                 [Page 25]
  1379. DRAFT                             CIPX                        April 1993
  1380.  
  1381.  
  1382. References
  1383.  
  1384.  
  1385. 1    Jacobson, Van, "Compressing TCP/IP Headers for Low-Speed Serial
  1386.      Links", RFC 1144, February 1990
  1387.  
  1388.  
  1389. 2    Simpson, W. A., "The Point-to-Point Protocol (PPP)", RFC 1331, May
  1390.      1992.
  1391.  
  1392.  
  1393. 3    Simpson, W. A., "The PPP Internet Packet Exchange Control Protocol
  1394.      (IPXCP)", an internet draft which is work in process, December 1992
  1395.  
  1396.  
  1397. 4    Allen, Michael, "Novell IPX Over Various WAN Media [IPXWAN]", RFC
  1398.      1362, August 1992
  1399.  
  1400. Acknowledgements
  1401.  
  1402.      This compression algorithm incorporates many ideas from the Van
  1403.      Jacobson TCP/IP header compression algorithm.
  1404.  
  1405.      Michael Allen from Novell provided a lot of valuable feedback in
  1406.      the design of this algorithm.  Marty Del Vecchio at Shiva Corp.
  1407.      made a couple of good observations.  Bill Simpson was, as always,
  1408.      very helpful.
  1409.  
  1410. Authors' Address
  1411.  
  1412.  
  1413.      Saroop Mathur
  1414.      Telebit Corp.
  1415.      1315 Chesapeake Terrace
  1416.      Sunnyvale, CA 94089-1100
  1417.      email: mathur@telebit.com
  1418.  
  1419.      Mark S. Lewis
  1420.      Telebit Corp.
  1421.      1315 Chesapeake Terrace
  1422.      Sunnyvale, CA 94089-1100
  1423.      email: Mark.S.Lewis@telebit.com
  1424.  
  1425.  
  1426.  
  1427.  
  1428.  
  1429.  
  1430.  
  1431.  
  1432.  
  1433.